home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000114-20000217
/
000051_news@columbia.edu _Mon Jan 17 19:55:56 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-02-16
|
6KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA01170
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 17 Jan 2000 19:55:56 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA00227
for kermit.misc@watsun.cc.columbia.edu; Mon, 17 Jan 2000 19:44:45 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
Subject: Re: MS-DOS Kermit, more capabalities
From: cangel@famvid.com
Message-ID: <OoOg4.6711$NU6.285660@tw12.nn.bcandid.com>
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Tue, 18 Jan 2000 00:24:14 GMT
To: kermit.misc@columbia.edu
On 2000-01-17 fdc@watsun.cc.columbia.edu(FrankdaCruz) said:
FD> Newsgroups: comp.protocols.kermit.misc
FD> In article <011700040222not-2-disclose@the.net>,
FD> <not-2-disclose@the.net> wrote:
FD> In the past two weeks or so, i couldn't but take note that MY
FD> NEED for a `ZMoDem' protocol has been disregarded from the start;
FD> Again, this is the Kermit Project, not the Zmodem Project. The
FD> source for Zmodem is Omen Technogy. If you want Zmodem software
FD> for DOS, you can get it from there.
FD> If you want Zmodem software with Kermit scripting for DOS, you're
FD> in the unenviable position of having to put it together yourself.
FD> It's not Omen's job to give you Kermit scripting, and it's not our
FD> job to give you Zmodem protocol.
You keep saying this and yet zmodem found it's way into the WIN95 Kermit.
Are you not aware that zmodem is in the WIN95 Kermit? If it doesn't
belong in there someone should remove it.
--8<--cut
FD> There are real people at work here. For some of us, it is our job.
FD> For others, all participation is voluntary, outside of their real
FD> jobs. The demands on our time are greater than the time available.
FD> We do our best to serve the largest number of people in the time we
FD> have.
Not quite sure what "real people" is supposed to mean in this context.
It reads as though you left out the word "important".
To say "We're really busy right now and are not able to get to anything
new at this time." would be a nicer way to say the same thing IMO.
FD> If you have bug reports, we welcome them. If you have questions of
FD> reasonable scope, we try to answer them. If you have suggestions,
FD> we'll listen to them, but we're not obligated to act on them. If we
FD> have a hundred thousand users anxiously waiting for some particular
FD> new feature in one of our programs, and one person looking for some
FD> other feature, all else being equal, I think the course is clear.
Could you give an example of this new feature you are all working on
that 100,000 users are anxiously waiting for?
--8<--cut
FD> Nobody is going to wade through a long script hunting for where
FD> the problem might be.
"Nobody" is a bit general. I intend to try the script (it takes only
10 or 15 minutes) and see what happens.
--8<--cut
FD> Nevertheless, we have been doing our best to show the BBS world how
FD> they can improve the situation. Read, for example, the article on
FD> MS-DOS Kermit and BBS's here:
FD> http://www.columbia.edu/kermit/newsn6.html#bbs
I have also mentioned the page on your website admitting that the
misunderstanding about the 94 byte packets was caused by using it as
the default setting for kermit for so many years. To be honest you
are the people that caused the problem but won't admit it.
--8<--cut
FD> MS-DOS Kermit and the environment it runs in have memory
FD> limitations. Now, I'm all for the idea of keeping old equipment
FD> alive and finding new uses for it, but when you consider that you
FD> can buy an Internet ready PC with 32 or 64MB of memory today for a
FD> fraction of the cost of the original IBM PC, maybe it's time to
FD> look at how much your time is worth.
There are many people who restore old automobiles, others restore old
furniture. Do you think they should buy only `new'?
For some this is a hobby and doing it with the original equipment or
close to the original is a challenge. It's not always about money.
Any fool can buy his way onto the Internet.
FD> Kermit 95, which you can run
FD> on Windows 95 and higher, is a "large memory model" version of
FD> Kermit that has few noticeable limitations in scripting. It is a
FD> better platform for long and complicated scripts because it has
FD> more capacity for them, because the underlying hardware and OS
FD> support bigger things.
Everybody sells Microsoft Windows. Truth is with a fast enough CPU
and enough memory any piece of crap software looks good. Reminds
me of the aerospace enigneering principle "With a big enough engine
anything will fly".
My interest in MSKermit is precisely that it does run on `legacy'
hardware. Not just that it executes - it works very effectively
and efficiently with a clean and useful user interface. The
macro language is a `grabber' for those of us accustom to having
one in our other terminal software.
If Kermit required massive amounts of memory and CPU cycles I would
have ignored it as just more `bloatware'.
--8<--cut
FD> Here are a couple observations that might be helpful:
FD> 2. The command to use for ASCII uploads is TRANSMIT. If you use
FD> that instead of OPEN READ, READ, ..., CLOSE READ, you won't
FD> experience any interference with the data.
I've used the TRANSMIT a few times. The entire screen goes haywire and
looks like a runaway ASM program (core dump?) but when it finally stops
the data has been transmitted. A bit unnevering to watch if you've had
many ASM programs try trashing your hard drive on you.
It appears to be functional but could use a better display format that
doesn't scare the heck out of you when you do use it IMO.
Charles.Angelich